1. Field of the Invention
The present invention relates generally to resource management and admission control of multimedia data flows and more specifically to management of multimedia data flows that are congested.
2. Description of Background Art
Multimedia data broadcast over an IP (Internet Protocol) infrastructure is a well-known way of transmitting and receiving multimedia data in today's information age. Unlike other forms of data (like text data), multimedia data is dependent upon an uninterrupted, constant flow of data packets (constant bit rate or CBR), to maintain the quality of the data received by an end user. The data packets in a multimedia data flow for standard cable TV viewing proceed through the IP network at a constant bit rate, such as 3.75 M bits per second which corresponds to 356 IP packets/second. Multimedia data flow for CATV or HDTV systems is transmitted through the IP network to an end user's set top box (STB). The set top box is designed to receive the multimedia data flow and format the data properly for display on the user's television.
Difficulties arise during management of multimedia data over an IP network during times of congestion. CBR multimedia data over IP networks cannot use conventional congestion control techniques such as RED, WRED, etc. Applying these methods causes severe degradation to all multimedia data flows traversing the link. In conventional systems during periods of congestion, all degraded multimedia data flows are allowed to pass through the IP network and are received by the set-top box. Because the STB is receiving some information, albeit corrupted information, the STB is unable to detect and report a problem to the data sender. Conventional congestion control methods do not always preserve the integrity of any of the multimedia data flows during a period of network link congestion.
When congestion occurs in a conventional network, a need arises to notify the source. Several congestion notification techniques exist for notifying a source of a congestion condition within a network. In Internet Control Message Protocol (ICMP), a gateway within the IP network may send a source quench message to an internet source of a multimedia data flow if the multimedia data is being sent too fast for the gateway to handle. A destination host may also send a source quench message if multimedia data flows arrive too fast to be processed. The source quench message is a request to the source to decrease the rate at which it is sending multimedia data flows to the internet destination. On receipt of a source quench message, the source host decreases the rate at which it is sending traffic to a predetermined rate or pauses the traffic to the specified destination for a predetermined period of time.
Another method for congestion notification is forward-explicit congestion notification (FECN) and backward-explicit congestion notification (BECN) within a Frame Relay network. FECN involves a header bit transmitted by the source (sending) terminal requesting that the destination (receiving) terminal slow down its requests for data. BECN (backward explicit congestion notification) involves a header bit transmitted by the destination terminal requesting that the source terminal send data more slowly. FECN and BECN are controlled by a single bit contained in the Frame Relay frame header. The Frame Relay frame header also contains a Discard Eligibility (DE) bit, which is used to identify less important traffic that can be dropped during periods of congestion.
Significant drawbacks are present within the ICMP and Frame Relay congestion notification techniques. The source quench message of ICMP and Frame Relay are sent only to the source. Moreover, the techniques do not take into consideration the fact that in today's media-rich environment, a single entity on a network may be a source or destination for multiple streams of data.
What is needed is an efficient way of improving network congestion notification.